Modern operating systems and applications are built from many components. A component is a self-contained software entity, offering a set of functions that can be used broadly by a variety of applications. A component is typically code, but it may also include the registry state, support files, etc. Component sharing enables efficiencies since individual components are used by more than one application. This enables efficiencies attributable to not having to re-write and test redundant code. This allows a developer to distribute a product to market more quickly and provides more stable code (when done properly).
Successful global component sharing requires that any shared component function exactly like previous versions of that component. In practice, however, 100 percent backward compatibility is difficult if not impossible to achieve because of the difficulty in testing all configurations in which the shared component may be used. Both newer and older applications end up using the same component, and over time, fixing and improving the component becomes increasingly difficult.
As well, the practical functionality of a component is not easily defined. Applications may become dependent on unintended side effects that are not considered part of the core function of the component. For example, an application may become dependent on a bug in the component, and when the component developer chooses to fix that bug, the application fails. The sheer volume of applications that use each component only deepens the problem.
This lack of backwards compatibility can result in the inability to deploy a new application without breaking applications already deployed or compromising the functionality of the new application. Any new application requires a version of a shared component that is different from the version already deployed.
Component Sharing
Most, if not all, operating systems have long embraced the concept of sharing. All operating systems balance the need to provide a robust, full set of services against the resource constraints of the hardware for which the operating system was designed. Until recently, CPU usage and disk space were very tight resources on the PC platform. An obvious way to fit operating system and application code into a small space has been to share code as much as possible. Among many other benefits, code sharing improves the leverage of hardware resources and reduces the amount of code that must be tested.
Sharing is not always restricted to code. In WINDOWS operating systems by MICROSOFT CORPORATION, application and component state can be found throughout the operating system in the form of Registry state, application-specific data storage in the file system, and WINDOWS application program interfaces (API) that expose global namespaces. Such sharing provides for a high level of interoperability between applications produced by multiple software vendors, bringing cost reduction and heightened software efficiency.
However, there are costs to sharing. Sharing means that applications become interdependent upon one other, introducing an element of fragility. Changes to one component may produce unintended effects in other components. Typically, an application may become dependent on a particular version of a shared component. Another application may be installed with an upgraded (or downgraded) version of that shared component, and the first application may suffer from that change. In the extreme, applications that once worked well mysteriously start to function oddly, or even fail. This condition is often referred to by developers as “DLL Hell.”
Isolation
The opposite of sharing in a system is isolation. Applications can be isolated by statically binding all resources and code into the application. However, complete isolation is not feasible today for applications that rely on COM components or any other globally stored system resources.
One solution discussed herein for reducing application fragility is to selectively isolate applications and components. Under this scenario, applications may all have access to the same component, but multiple versions of that component now become available. Component producers have the freedom to produce new versions of old components, making improvements and fixing bugs. Customers, on the other hand, can choose the version that fits with a particular application.
With components, the key is to provide the version that is appropriate to each application and isolate the different versions from each other. Further, with redirection, applications can be configured to use the component version that fits with that particular application, regardless of what other versions are currently deployed or will be deployed in the future. In addition, a developer may apply a bug fix to a component in the context of a single application without having to be concerned with the effect of the bug fix on other applications.